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PARSING A PACKET HEADER address and a field 32 lhat indicates the TCP deslination port 

address. Another field 34 of Ihe TCP protocol header 22a 

UALKOKUUiNU indicate a sequence number lhat is used to concatenate 

The invenlioD relates to parsing a packet header. received packets of an associated flow. Packets 8 that have 

Referring lo FICi. I, a server 12 may communicate with a 5 ,he same IP addresses, transport layer port addresses and 

client 10 by transmitting packets 8, or frames, of information security attributes arc part of the same flow, and a sequence 

over a network 18 pursuant to a network protocol. As an number (described below) indicates the order of a particular 

example, the network protocol may be a Transmission pjckd 8 in that flow 

Control Prc^cK^oVlnleraet Protocol (TCP/IP), and asa result. ^^.^ ^ ^^^^^ ^ _ 

"^^ '''"'"'i^'o"' T'[, -"7 '■"Pl'=™'" P'"'°'»' 10 tially numbered even though the data bytes may be divided 

suchasTCP,aPs.acksl7 a„d 19. respj^^^ diff,^„, p,,^,^, g ^^he flow. To accomplish 

10 (as an example), the TCPIP slack 17 conceptuaUy ^^.^.y 3^ .j,^ ^^^^^^ 22a may indicate 

divides the client's soltware and hardware protocol func- n,^„u„,„„ha, idcmiflesthc firstbyte numberofthc 

tions mto five hierarchical layers 16 (lusted h'«";^hical ^ j^,^ j„ , 

order): an application layer 16« (the highest layer), a trans- ,5 ^^^^ ^ ^ j,^,^ ^^^^^^ 

poa layer 16ft, a network layer 16c. a data link layer 16</and ^^^^^ j.^^ g i^^i^^,^ 

a ph>-s.cal layer 16*r (the lowest layer). fii^, byte in the next packet 8 of the flow. 

i„r;: Ci^llrnirf^rin^^^^^^^ . TCP protocol header 22. may include a field 38 that 

e.ablishesphysiJ— ^^^^ 

EeTiX^:^^^^^^^ indica.esc.n.roUndstatusDags.Forexample,thefi^^^ 
,ayer,6c.ecogni-,.es^.andL^^ 

the data link aycr \6d performs this function, hi this *^ ., .11.0 

uaiu I y • II • u«.u « 101 icalc whelhcr or not a par icular packet 8 carries 

manner the data link aycr \6d typically is both a software ,c uvm^i r * • V r r 

' \ / jf J acknowledumenl information that us used for purposes of 

and harx ware layer hat may, for transmission purposes, 'i', ' , , i i \ .1,^* 

, I !u A * , i^i J;mJ.i .-r,!^ " ha ndshakina. In this manner, an ackiwwledgment packet 

cause the clien 10 o package the data lo be transmitted into uauu u «v « v • 1 1 j . 7 .u 

the packets 8. For pu Joses of receiving packets 8, the data 'yP'"'ly "oes not but may) '"C ude da . « re^^" 

link layer I6rf may. as another example, cau.se the client 10 « ""^^ acknowledgment p cket after the 
to determine the imegrily of the incoming packets 8 by ^ '^'''''"T'''t,\'' 2ZZt T^l — .he 

determining if the incoming packets 8 generally conform to ""-nple) «f packets f om the sender. In thts manner, the 

predefined formats and if Ihe data of the packets comply rece.pt of an acknowledgmem packet by the sender ind.«s 

with cvclic adundancy check (CRC) co^lek or o.hcr error 'h^t ^ predetemined number of packets we re succe^fuUv 

1 I II, 1 . /ai* Ur.h Uw*.r li?// mav tfansmilted. The TCP protocol header 22a may also include 

correction c-odes ol the packets. lUe data link layer 16rf may ^ ^^^^ ^^^^ .^^.^^^^P ^ ^^^.^^^ ^^^^^^ J^^^^^ ^^^^^ 

atso perfom, addre.ss hitcnng. , " " "window") that the sender may transmit before receiving 

■me network layer 16c typically ts a «> ' ware layer that is acknowledgment packet that at lea.st indicates some of the 

responsible for routing the packets 8 over he network 18, In ^^^^ successively received. Other fields arc [wssible. 

thismanner. the network layer 16c 'VP-^ 'y ^"^^^^^^^^^ such as a checksum field 44 and an utgem pointer field 42. 

10 to a.ss.8n and decode Internet Protocol (IP) addres.ses that ^^ ^^^^ ^2 j^jj^^,^^ ^j^^, 

Identify ent.t.es that are coupled to the netv^ork 18 such as « , J^„„,„, 4,,,,^ „„„ber at which uigem data is 

the chcnl 10 and the server 12. The transport layer lot) located 

typically Ls a software laver thai Ls rcspoasible for such v " ^ , , • ^ . . u 

things L reliable data transfer between two endpoinls and As an example, software that is associated with the 

may use sequencing, error control and general flow control transport 166 and network 16c layers, when executed by a 

of the packets 8 to achieve it. The traasport layer Hb may 45 ^he client 10, typically causes the client 10 to 

cause the client 10 to implement a specific protocol, such as parse the information lhal is indicated by the protoa)l header 

the TCP protocol or a User Datagram Protocol (UDP), as 22 lo facilitate additional processing of the packet 8. 

examples ITie application layer. 16.7 typically includes However, the execution of ihe «,flware may mtroduce 

network applications lhal, upon cxeculion, cause the client Mays lhat impede the communication ol packets 8 between 

10 lo generate and receive the data of the packets 8. 50 ^^'^"^ ^^"^ ^^'"^^ 

Referring lo FIG. 2, a typical packet 8 may include an IP Thus, there is a continuing need to address one or more of 
header 20 that indicates such information as the source and the problems slated above, 
destination IP addresses for the packet 8. The packet 8 may SUMMARY 
include a security header 23 lhal indicates a security proto- 
col (e.g., an FPSec protocol) and altribulcs of the packet 8, 55 In one embodiment of the invention, a method for use 
and the packet 8 may include a transport protocol header 22 with a computer system includes receiving a packet lhat 
(a TCP or an UDP protocol header, as examples) lhal is includes a header. The header indicates at leasi one charac- 
specific to the Iransport prolcK'ol being used. As an example, leristic lhat is asst)cialed with a layer of a prolocx)! slack. The 
a TCP protocol header might indicate a TCP deslination port packet is parsed with a network controller to extract the 
and a TCP st>urce port that uniquely identify Ihe applications m characlerislicXs), and ihe handle is passed from the network 
that cause Ihe client 10 ami server 12 lo Iransmil and receive controller lo indicate the characleristic(s). 
the packets 8. Hie packet 8 may also include a dala portion In another embodiment, an apparatus is used with a 
24, the contents of which are furnished by the source computer sysiem lhat is capable of executing software of a 
application; and a trailer 26 that is used for encryption protocol stack to extract at least one characteristic of a 
purpases. 65 packet. The apparatus includes an interface and a circuit. 

Referring lo FIG. 3, as an example, a TCP protocol header The interface is adapted lo receive the packet, and the packet 

22rt may include a field 30 that indicates the TCP stiurcc port includes a header lhal indicates the characteristic(s). The 
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circuit is adapted to parse the header to extract the 
characteristic(s) of the packet without causing the computer 
to execute the software and process the packet based on the 
extracted characterislic(s). 

In yet another embodiment, a computer system includes a 
processor and a peripheral device. The processor Is adapted 
to execute software of a network stack to extract at least one 
characteristic of a packet. The packet includes a header that 
indicates the characteristic(s). The peripheral device is 
adapted to receive the packet and parse the header to extract 
the characterislic(s). The peripheral device is also adapted to 
at least partially process the packet based on the extracted 
charactcristic(s). 

BRIEF DESCRIPTION OF THE DRAWING 

FIG. I is a schematic diagram of a network of computers 
according to the prior art. 

RG. 2 is a schematic diagram of a packet transmitted over 
the network shown in FIG. I. 

FIG. 3 is an illustration of a prolocx>l header of the packet 
of FIG. 2. 

RG. 4 Ls a schematic diagram of a computer system 
according to an embodiment of the invention. 

FIG. 5 is a schematic diagram of a network controller of 
FIG. 4. 

HG. 6 is an illu.stration of a flow tuple stored in memory 
of the network controller of FIG. 5. 

RG. 7 is a schematic diagram illustrating the transfer of 
packet data according to an embodiment of the invention. 

RG. 8 is a schematic diagram illustrating the transfer of 
packet data lictwcen layers of the network stack of the prior 
an. 

RG. 9 is a flow diagram illustrating parsing of packet data 
by a receive parser of the network controller of FIG. 5. 

RGS. 10 and 12 arc flow diagrams illu.strating operation 
of a zero copy parser of the network controller of RG. 5 
according to an embodiment of the invention. 

RG. 11 is a slate diagram illustrating operation of the 
network controller of FIG. 5 according to an embodiment of 
the invention. 

DETAILED DESCRIPTION 

Referring to FIG. 4, an embodiment 50 of a computer 
system in accordance with the invention includes a network 
controller 52 (a local area network (I-AN) controller, for 
cxumple) that communicates packets of information with 
other networked computer systems via at least one network 
wire 53. Unlike conventional network controllers, the net- 
work controller 52 is adapted to perform functions that arc 
typically implemented by a processor 54 (a central process- 
ing unit (CPU), for example) that executes one or more 
software layers (a network layer and a transport layer, as 55 
examples) of a network protocol stack (a 'rcP/lP stack, for 
example). As an example, these functions may include 
parsing headers of incoming packets to obtain characteristics 
(of tlic packet) that typically arc cxiractc^l by execution of 
the software layers. 60 

The characteristics, in turn, may identify an application 
that is to receive data of the packet. In this context, the term 
"application'* may generally refer to a user of one of the 
protocol layers (layers 1, 2, 3 or 4. as examples). Due to this 
identification by the network controller 52, the network 65 
controller 52 (and not a software layer of the stack) may 
directly control the transfer of the packet data to a buffer (in 
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a system memory 56) that Ls associated with the application. 
As a result of this arrangement, data transfers between the 
network controller 52 and the system memory 56 may take 
less time and more efficiently use memory space, as further 
5 described below. 

Referring to RG. 5, the network controller 52 may 
include hardware, such as a receive path 92, to perform 
functions to process packets that are received from the 
network. For example, the receive path 92 may include a 
30 receive parser 98 to parse a header of each packet to extract 
characteristics of the packet, such as characteristics that 
associate a particular flow with the packet. Because the 
receive path 92 may Ik receiving incoming packets from 
many different flows, the receive path 92 may include a 
15 memory 100 that stores entries, called flow tuples 140. Each 
flow tuple 140 uniquely identifies a flow that is to be parsed 
by the network controller 52. As further described below, the 
flows indicated by the flow tuples 140 may be changed by 
the processor's execution of a driver program 57. 

The receive parser 98 may use the stored flow tuples 140 
in the following manner. First, the receive parser 98 may 
interact with the memory 100 to compare parsed information 
from the incoming packet with the flow tuples 140 to 
determine if the inaiming flow Ls one of the flows indicated 
by the flow tuples 140, i.e., the receive parser 98 determines 
if a "flow tuple hit,'* occurs. If a flow tuple hit occurs, the 
receive parser 98 may parse packets that arc a.ssociaied with 
the flow, and other circuitry (of the ct>ntroller 52) may also 
process the packet based on the delected flow, as further 
described below. 

Referring also to FIG. 6, each flow tuple 140 may include 
fields that identify characteri.stics of a particular flow. As an 
example, in some embodiments, at least one of the flow 
tuples 140 may be associated with a Transmission Control 
^' Protocol (TCP), a User Datagram Protocol (UDP) or a 
Real -time Transport Protocol, as examples. The flow tuple 
140 may include a field 142 that indicates an internet 
protocol (IP) destination address (i.e., the address of the 
computer system to receive the packet); a field 144 that 
indicates an IP source address (i.e., the address of a com- 
puter system to transmit the packet); a field 146 that indi- 
cates a TCP destination port (i.e., the address of the appli- 
cation that caused generation of the packet); a field 148 that 
indicates a TCP source port (i.e., the address of the appli- 
cation that Ls to receive the packet); a field 150 that indicates 
security/authentication attributes of the packet; and a secu- 
rity parameter index (SPI) field 152 that may be used by the 
computer system 50 to identify a secure flow. Other flow 
tuples 140 may be associated with other network protocols, 
such as a User Datagram Protocol (UDP), for example. 

In some emlx)diments, the receive parser 98 may u.se a 
subset of the flow tuple 140 to identify a particular flow. For 
example, in some embodiments, the receive parser 98 may 
use the fields 142, 150 and 152 to identify a flow tuple hit. 
As described further below, the fields 142, 144, 146 and 148 
may be used to identify specific types of flow, such as, zero 
copy flows. 

Tlie alxive references to specific network protocols are 
intended to be examples only and are not intended to limit 
the scope of the invention. Additional flow tuples 140 may 
be stored in the memory 100 and exLsting flow tuples 140 
may be removed from the memory 100 via execution of the 
driver program 57 by the processor 54. In some 
embodiments, the memory 100 may also store information 
fields 141. Each field 141 may be as.sociatcd with a particu- 
lar flow tuple 140 and may indicate, lor example, a handler 
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that identifies (for the network protocol stack) the flow and 
a pointer to a buffer of a system memory 56, as further 
described below. 

If the receive parser 98 recognizes (via the flow tuples 
140) the flow that is associated with the incoming packet, 
then the receive path 92 may further process the packet. In 
some embodiments, the receive parser 98 may indicate (to 
other circuitry of the network controller 52 and eventually to 
a network protocol stack) recognition of the flow associated 
with a particular packet and other detected attributes of the 
packet. 

If the receive parser 98 doesn*t recognize the flow, then 
the receive path 92 passes the incoming packet via a 
Peripheral Component Interconnect (PCI) interface 130 to 
software layers of a network protocol slack (a TCIVIP stack, 
for example) of the computer system 50 for processing. The 
PCI Specification is available from The PCI Special Interest 
Group, Portland, Oreg, 97214. Other bus interfaces may be 
used in place of the PCI interface 130 to interface the 
network controller 52 to buses other than a PCI bus. In some 
embodiments, the computer system 50 may execute an 
operating system that provides at least a portion of some 
layers (network and transport layers, for example) of the 
protocol slack. 

In some embodiments, even if the receive parser 98 
recognizes Ihe flow, additional information may be needed 
before receive path 92 further prt>cesses the incoming packet 
52. For example, an authentication/encryption engine 102 
may authenticate and/or decrypt the data portion of (he 
incoming packet based on the information that is indicated 
by ihc IP security header of the packet. In this manner, if the 
IP security header indicates that the data portion of the 
incoming packet is encrypted, then the engine 102 may need 
a key to decrypt the data portion. 

For purpo.ses of providing the key to the engine t02, the 
network controller 52 may include a key memory 104 that 
stores different keys that may be indexed by the different 
associated flows, for example. Additional keys may be 
stored in the key memory 104 by the processor's execution 
of the driver program 57, and existing keys may be removed 
from the key memory 104 by the processor's execution of 
the driver program 57. In this manner, if the engine 102 
determines that the particular decryption key is not stored in 
the key memory 104, then the engine 102 may submit a 
request (via the PCI interface 130) to the driver program 57 
(see PIG. 4) for the key. In this manner, the driver program 
57, when executed by the processor 54, may cause the 
processor 54 to furnish the key in response to the request and 
interact with the PCI interfacx 130 to store the key in the key 
memory 104. In some embodiments, if (he key is unavail- 
al)lc (i.e., the key is not available from the driver program 57 
or is not stored in the key memory 104), then Ihc engine 102 
does not decrypt the data portion of the packet. Instead, Ihe 
PCI interface 130 stores the encrypted data in a prcdeter- 55 
mined location of the system memory 56 (sec FIG. 4) so that 
software of one or more layers of the protocol stack may be 
executed to decrypt the data portion of the incoming packet. 

After the parsing, the processing of the packet by the 
network controller 52 may include bypas.sing the execnition 60 
of one or more software layers that are associated with the 
network protocol slack. For example, the receive path 92 
may include a zero copy parser 110 that, via the PCI 
interface 130, may copy data associated with the packet into 
a memory buffer 304 (see FIG. 7) that is associated with the 65 
application layer. In this manner, an application may have 
one or more associalal buffers for receiving the packet data. 
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The operating system creates and maintains the buffers 304 
in a virtual address space, and the operating system reserves 
a multiple number of physical four kilobyte (KB) pages for 
each buffer 304. The operating system also associates each 
5 buffer 304 with a particular application so that Ihe applica- 
tion may use the data stored in the buffer 304. 

As descri1>ed below, to accomplish the direct transfer of 
packet data from the network controller 52 to the buffers 
304, the operating system causes the processor 54 to provide 
10 a pointer (to Ihc network controller 52) that points to one of 
Ihe buffers 304. The indicated buffer 304 may be a buffer 
allocated by the application for its sole use or a buffer Ihe 
operating system hands to the network controller 52 to be 
associated with one of the predefined flows that arc to be 
55 ser\'iced with zero copy. In Ihe latter case, the operating 
system will later re-map the buffer to the virtual address 
space of the application. 'ITie zero copy purser llO uses the 
flow handle to associate the frame with a zero copy buffer 
and copy the data directly into that buffer. The above- 
20 descril>cd arrangement of traiisferring data into the buffers 
304 is to be contrasted to conventional arrangements that 
may use intermediate buffers (that are associated with the 
data link and/or the transport layer) to transfer packet data 
from Ihe network controller lo application layer buffers, as 
25 described below. 

Referring to FIG. 8, for example, a typical network 
controller 300 does not directly transfer packet data into the 
buffers 304 because ihe typical network controller 300 does 
not parse Ihe incoming packets to obtain information that 
identifies Ihe flow or destination application. Instead, the 
typical network conlroller 300 transfers the data portion of 
Ihe packet into packet buffers 302 that are associated with 
Ihe data link layer. In contra.st to the buffers 304, each buffer 
302 may have a size range of approximately 1518 bytes (as 
an example), i.e., the approximate size range of data for a 
particular packet. The execution of the transport layer (by 
Ihe processor 54) subsequently associates the data with Ihc 
appropriate applications and causes the data lo be transferred 
from the buffers 302 to Ihe buffers 304. 

Referring back to FIG. 7, in contrast to the conventional 
arrangement described above, the network controller 52 may 
use the zero copy parser 110 to bypass ihe buffers 302 and 
copy the data portion of the packet directly into Ihe appro- 
priate buffer 3(M. To accomplish Ihis, Ihe zero copy parser 
110 (see FIG. 5) may receive an indication of Ihe TCP 
destination port (as an example) from Ihe receive parser 98 
that, as described above, extracts this information from the 
header. The TCP (or other layer 4 prototx>l, e.g., RTP) 
destination port uniquely idenii fies the application that is lo 
receive the data and thus, identifies the appropriate buffer 
304 for the packet data. Besides traasferring Ihe data por- 
tions to Ihe buffers 304, the zero copy parser 110 may handle 
control issues between the network controller 52 and Ihe 
protocol Slack and may handle ca.ses where an incoming 
packet is missing, as described below. 

The zero copy parser may use a flow context memory 112 
to store flow context fields 113 that indicates the particular 
flows in which zero copying is lo be performed. Each 
context field 113 may be associated with an information field 
115 (also stored in the flow context memory 112) that 
indicates, for example, handles that are associated with the 
various flows indicated by the flow conlexl fields 113 and 
other information like addresses, for example. 

Referring to FIG. 5, besides the components described 
alx>ve. the receive path 92 may also include one or more 
first-in-first-oul (FIFO) memories 106 to temporarily store 
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the incoming packets through the receive path 92. A check- In some embodiments, the receive 98 and zero copy 110 

sum engine 108 (of the receive path 92) may be coupled parsers may include one or more state machines, countcr(s) 

between the FIFO raemory(ies) 106 and the PCI interface and liraer(s). as examples, to perform the following func- 

130 for purposes of verifying checksums that are embedded lions for each incoming packet. In the following, il is 

in the packets. 5 assumed that the particular flow being dcscri!>cd is a zero 

l^e receive path 92 may be interfaced to a PCI bus 72 via copy flow. However, the flow may or may not be a zero copy 

the PCI interface 130. llie PCI interface 130 may include an flow in some embodiments. Referring to V\G, 9, the receive 

emulated direct memory access (DMA) engine 131 that is parser 98 may parse (block 200) the header of each incoming 

used for purposes of Iraosfcrring the data portions of the packet. From the parsed information, the receive parser 98 

packets directly into the buffers 304 or 302 (when zero copy jq may determine if the packet needs authentication or 

is not used). In this manner, the zero copy parser 110 may decryption, as indicated in diamond 201. 

use one of a predetermined number (sixteen, for example) of If authentication or encryption Ls needed, then the receive 

DMA channels emulated by the DMA engine 131 to transfer parser 98 may use the parsed information from the header to 

the data into the appropriate buffer 304. In some determine (diamond 216) if a flow tuple hit has occurred. If 

embodiments, il is possible for each of the channels to be not, the receiver parser 98 transfers control to the zero copy 

associated with a particular buffer 304. However, in some parser 110 that performs end of packet checks, as depicted 

embodiments, when the protocol stack (instead of the zero in block 202. Otherwise, the receive parser 98 determines if 

copy parser 110) is used to transfer the data portions of the the associated key is available in the key memory 104, as 

packets the DMA engine 131 may use a lower number (one, depicted in diamond 220. If the key is available, then the 

for example) of channels for these transfers. receive parser 98 may start authentication and/or decryption 

In some embodiments, the receive path 92 may include of the packet as indicated in block 218 before passing 

additional circuitry, such as a scrial-to-parallel conversion control to the zero copy parser 110 that may perform a zero 

circuit 96 that may receive a serial stream of bits from a copy of the packet, as indicated in block 202. If the key is 

network interface 90 when a packet is received from the not available, the receive parser 98 may transfer control to 

Tietwork wire 53. In this manner, the conversion circuit 96 25 the zero copy parser 110 to perform a zero copy operation, 

packages the bits into bytes and provides these bytes to the as indicated in block 202. 

receive parser 98. llie network interface 90 may be coupled After performing the zero copy operation (block 202), the 

to generate and receive signals to/from the network wire 53. zero copy parser 110 may perform end of packet checks, as 

In addition to the receive path 92, the network controller indicated by block 204. In these checks, the receive parser 

52 may include other hardware circuitry, such as a transmit 30 98 may perform checks that typically arc a.ssociaicd with the 

path 94, to transmit outgoing packets to the network. In the data link layer. For example, the receive parser 98 may 

transmit path 94. the network controller 52 may include a ensure that the packet indicates the correct Ethernet MAC 

transmit parser 114 that is coupled to the PCI interface 130 address, no cyclic redundancy check (CRC) errors have 

to receive outgoing packet data from the computer system occurred, no receive status errors (collision, overrun, 

50 and form the header on the packets. To accomplish this, 35 minimum/maximum frame length errors, as examples) have 

in .some embodiments, the transmit parser 114 stores the occurred and the length of the frame is greater than a 

headers of predetermined flows in a header memory 1 16. minimum number (64, for example) of bytes. ITie receive 

Because the headers of a particular flow may indicate a parser 98 may perform checks that typically are associated 

significant amount of the same information (port and IP with the network layer For example, the receive parser 98 

addresses, for example), the transmit parser 114 may slightly 40 may check on the size of the IP packet header, a>mpute a 

modify the stored header for each outgoing packet and checksum of the IP header, determine if the computed 

assemble the modified header onto the outgoing packet. As checksum of the IP header is consistent with a checksum 

an example, for a particular How, the transmit parser 114 indicated by the IP header, ensure that the packet indicates 

may retrieve the header from the header memory 116 and the cxirrect IP destination address and determine if the IP 

parse the header to add such information as sequence and 45 indicates a recognized network protocol (the TCP or UDP 

acknowledgmeni numbers (as examples) to the header of the protocols, a.s exiimple.s). The receive parser 98 may also 

outgoing packet. A checksum engine 120 may compute perform checks that are typically associated with functions 

checksums for the IP and network headers of the outgoing that are performed by the processor's execution of software 

packet and incorporate the checksums into the packet. that is a.s.sociated with the transport layer. For example, the 

The transmit path 94 may also include an authentication 50 receive parser 98 may determine if the size of the protocol 

and encr>'ption engine 126 that may encrypt and/or authen- header is within predefined limits, may compute a checksum 

ticate the data of the outgoing packets. In this manner, aU of the protocol header, and may determine if flags called 

packets of a particular flow may be encrypted and/'or autben- ACK, URG, PSI I, RST, FIN and/or SYN flags are set. If the 

licateil via a key that is a.ssociated with the flow, and the keys PSIl flag is set, then the receiver parser 98,may indicate this 

for the different flows may be stored in a key memory 124. 55 event to the driver program. If the RST, FIN or SYN flags 

In some embodiments, new keys may l>e added to the key arc set, the receive parser 98 may surrender control to the 

memory 124 and existing keys may be modified or deleted transport layer. If the ACK flag is sent, then the receive 

by information passed thrx>ugli the transmit path 94 via fields parser 98 may interact either with the driver program 57 or 

of a control packet. The transmit path 94 may also include Ihc transmit path 94 to transmit an acknowledgment packet, 

one or more FIFO memories 122 to synchronize the flow of 6() as further described below. 

the packets through the transmit path 94. A parallel- to-serial After the checks are complete, the zero copy parser 110 

conversion circuit 128 may l>e coupled to the FIFO memory may determine (diamond 205) whether a data link layer 

(ies) 122 to retrieve packets that are ready for transmission occurred, an error that may cause the packet to be unu.sablc. 

for purposes of serializing the data of the outgoing packets. If this is the case, then the zero copy parser 110 may reclaim 

Once serialized, the circuit 128 may pa.ss the data to the 65 (block 205) the memory that the driver program allocated 

network interface 90 for transmission to the network wire for the packet, reclaim (block 207) the memory that was 

53. allocated for zero tx>py of the packet and reset (block 209) 
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the DMA channel (emulated by the DMA engine 131) that If the zero copy parser 98 (by using the flow context 

was associated with the packet. Otherwise, the zero copy indications 113) detects that packets from a particular flow 

parser 110 compiles an error statistics slack for the protocol are to be zeR> copied, then the network controller 52 

slack. transitions lo a ZERO COPY state. In the ZERO COPY 

Referriofi to FIG. 10, the zero copy parser UO may 5 state, the zero copy parser 98 uses the information field 115 

perform the following functions to perform a zero copy tliat is associated with each zero copy now to identify such 

operation, l-irst, the zero copy parser 110 may determine the information as the handle that is passed to the network stack 

memory address at which to store the data, as ftirther (to identify the flow) and the pointer to the appropnate 

described below: Next, the zero copy parser 110 may deter- application buffer 304. If a pomter to another buffer 304 is 

mine (diamond 258) whether a packet is missing, and if so, needed, then the zero copy parser 98 requests another 

the zero copy parser UO reserves (block 260) memory space pointer from the driver program 57. In response, the driver 

for the missing packet. The zero copy parser UO subsc- program 57 (in a GET_NEXT__BUFF2 slate) transfers an 

quently performs (block 262) a zero copy operation to copy indication of the pointer to the network controller 52 for use 

the packet into the memor>' 56. by the zero copy parser 110. In other embodiments it is the 

Next, the zero copy parser 110 may update (block 264) a resjwnsibility of the application or stack to provide enough 

count of received packets for the flow. The zero copy parser buffers for a zero copy flow. In some embodiments, in case 

110 then determines (diamond 266) whether it is time to it^e network controller 52 runs out of buffers, the network 

transmit an acknowledgment packet back to the sender of controller 52 u.scs the software-based receive procedure. Tlic 

the packet based on the number of received packets in the j^^^^ (.^py parser UO, in response, may update the informa- 

flow. In thLs manner, if the count exceeds a predetermined jj^j, u^j^ 

numl>cr, then the receive parser 98 may cither (depending on 20 ^^^^ embodiments, the driver program 57 may cause 

the particular embodinaent) "of'^y (^lofk 26» the dnver ^^^^ processor 54 to exit the MONITOR state or ZERO 

program 57 (see HG. 4 or notify (block 270) the transmi ^^^y^^^^^ 3^,, ^^e IDT.E slate. The driver program 

parser 114 of the need lo r^^n^Tr U4^^^^^ 57 may cau^ the proce^^or 54 to interact with the PCI 

packet. Thus, in he latter case, the transmit parser 114 may . . ^- i ;„,t; 

be adapted t^ generate an acknowledgment^^acket, as no 25 interface 131 to add/remove a particular flow context indi- 

data fo[ the data portion may Ik nccdct! from the application cation U 3 to/from the memory U2 and may cause the 

layer. The receive parser 98 transitions from either block 268 processor 54 to add/remove a particular flow tuple 140 
or 270 to diamond 200-(sec^FlG.-.9)Jo_check_for„another_^ to/from the flow memory 100, 

received nacket. Afte r a n . ,Ac kn Q w l edgtne.nt^pa^^ ^ ^ Referring to HG. 12, in the performance of the zero copy 

t ransniitte d .^th<^r^^Si!paFsM operation, the zea) copy parser may perform the following 

^^JS^^SSSlf^SfrS^^ functions to transfer the packet data directly to the buffers 

"^"^tTdiagraiFthat ifiustrates transferof control from the 304. First, the zero copy parser UO may determine if control 

stack to the network controller 52 in a synchronized manner, of the traasfer needs to be synchronized between the zero 

per flow, of the receive path 92 is illustrated in FIG. 11. copy parser UO and execution of the .software that is 

When the software that is associated with the network 35 associated with the layers (the data link and traasport layers, 

protocol stack Ls handling the parsing and processing of the as examples) of the network protocol slack. In this context, 

packets, then the receive path 92 remains in an IDLE state. Ihe term "synchronization" generally refers lo communica- 

However, in some embodiments, although the transport tion between the stack and the zero copy parser 110 for 

la ver may be executed bv the processor 54 lo initially handle purposes of determining a transition point at which one of 

the packets, subsequently control of the processing may be 40 i^e entities (the stack or the zero copy parser UO) takes 

transferred to the network controfler 52. In this manner, the control from the other and begins transferring data mto the 

processor 54, ihmugh execution of the driver program 57, buffers 304. Without synchronization, mis.sing packets may 

may interact with the PCI interface 130 lo place the receive not be detected. Therefore, when control passes from the 

path 92 in a MONITOR state. slack lo the parser UO (and vice versa), synchronization may 

In the MONITOR slate, the receive parser 98 checks the 45 "ced to occur, as depicted in block 254. 

integrity of the incoming packets that arc associated with Thus, one scenario where synchronization may be needed 

predetermined Hows (as indicated by the flow tuples 140) is when the zero cx>py parser UO initially takes over the 

and indicates the results of the check, as described above. function of directly transferring the data portions into the 

For each predetermined flow to be monitored, the memory buffers 304. In this manner, if the z^ro copy parser UO 

100 may store an information field 141 that is associated 50 determines (diamond 250) l hat the current packet is the first 

with the flow. As an example, the information 141 may packet being handled by the zero copy parser UO. then the 

indicate a handle that indicates the flow to the network stack, parser UO synchronizes the packet storage, as depicted by 

a TCPsequence number (as an example) and a pointer to the block 254. If not. the zero copy parser UO determines 

appropriate network layer buffer 302 (when zero LX>py is not (diamond 252) if an error has occurral, as descnbcd below, 

used). If the receive parser 98 needs a pointer to another 55 For purposes of determining when the transition occurs, the 

buffer 302, then the receive parser 98 may notify the driver zero copy parser UO may continually monitor the status of 

program 57 thai (in a GET_NEXT„BUFF1 slate), in turn, a bit that may be selectively set by the driver program 57, for 

prttvides the pointer to the next buffer 302, and in response. example. Another scenario where synchronization u> needed 

the receive pareer 98 may update the as.socialed field 141. is when an error occurs when the zero copy parser UO is 

The GET_NEXT_RUFF1 stale is related lo buffers 304 60 copying the packet dala into the buffers 304. l or example, 

and is used in the case when zero copy is used. This slate as a result of the error, the stack may temporarily resume 

machine and this particular .state transition may not be ased control of the transfer before the zeri) copy parser UO 

in some embodiments. The stack may also communicate to regains control. 'Ilius if the zero copy parser 1 10 dctcrmuics 

ihe network controller 52 lo start zero copy from sequence (diamond 252) that an error has occurred, the zero copy 

number X or greater than X and from memory address Y that 65 parser UO may traasition to the block 254. 

corT^i.sponds to that X,thas eliminating this synchronization Synchronization may occur in numerous ways. For 

process, example, the zero mpy parser 110 may embed a predetcr- 
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mined code into a pajticular packet status information to techniques. Other network protocols and other protx)col 

indicate to the stack that the zero copy parser 110 handles the stacks may be used. 

transfer of subsequent packets. ITic stack may do the same. While (he iovcntioo has been disclosed with respect to a 

Occa.sionally. the incoming packets of a particular flow jiniited number of ernbodiments, ihose skilled in the art, 

• \.r Ti, ,,JL,i- « u\^r^ 5 havma tlie benefit of thiS disclosure. Will appreciate numer- 

may be received out of sequence, ms ma^^^^^^^^^ a probkm variations therefrom' It is intended 

becau.se the zero copy parser 110 may store the data fmm ^^^^ ^ ^^^^ ^^^^^ modifications and 

sequential packets one after the other in a particular biifier ^^.^^^^^^^^^l^ f^i, ,vithin the true spirit and scope of the 

304. Tor example, packet number *767" may be received invention 

before packet number "266," an event that may cause claimed is: 

problems if the data for packet number "267" is stored l. a method for use with a computer system, comprising: 

immediately after the data for packet number "265." To receiving a packet that includes a header, the header 

prevent this scenario from occurring, m some embodiments, indicating ai least one characteristic that is a.<isociated 

the zero copy parser 110 may reserve a region 308 (sec FIG. ^ i^y^^ ^f a multiple layer protocol stack; 

7) in the particular butter 304 for the missing packet data, as parsing the packet with a network controller to extract 

indicated in block 260 (i-IG. 11). For purposes of determin- ^5 j-^jj y^,^^^ ^^^^ characteristic; and 

ing the size of the missing packet (and thus, the amount of passing a handle from ihe network controller lo indicate 

memory space to reserve), the zero ct>py parser 110 may use ^^^^ ^^^^^ characteristic. 

the sequence numbers that are indicated by the adjacent 2. I'hc method of claim I, wherein the act of passing 

packets in the sequence. In this manner, the sequence comprises: 

number indicates the byte numl)cr of the next successive 20 pa^^ing the handle to another layer of the protocol .slack, 

packet. Thus, for the example described above, the acknowl- 3 jhc method of claim 1, wherein said at least one 

edgnient numbers indicated by the packet numbers "265" characteristic comprises: 

and "267" may be ascd to determine the boundaries of the 3 number associated with an application program, 

region 308, 4. The method of claim 1, wherein the layer a>mprises a 

The zero copy parser 110 subsequently interacts with the data link layer. 

PCI interface 130 to set up the appropriate DMA channel I o 5. The method of claim I, wherein said at least one 

perform a zero copy (.step 262) of the packet data into the characteristic compri.scs: 

appropriate bu(Ter304. The zero copy parser llOdelermines a type of the packet. 

(he appropriate buffer 304 via the destination port that is 6. The method of claim 1, wherein Ihe handle associates 

pmvided by the receive parser 98. the packet with ^ flow. 

„ ^ . . , ^ 1. 'J I. . f .11 7- The method ol claim 1, further comprtsing: 

Rcfcrrinc back to F G. 4, besides the network controller .... .... , , j . 1 . u ^ 

52, .he com%.cr system 50 may mcludc a processor 54 .ha. ^'if::^' IZ^Z^c^^:^' ' 

i. coupled .o a hos. bus ^"J" •'■'^ 8. Z m . ^ oTc U m 1 Sr^^^^ 

processor may ccncrally refer to one or more central ..... , . r .u . • j 
- ui y y 7 r^;r>rr^^rr^^^^ ^ ' associatcd With the packcl in a region of memory that is used 

processing units (CPUs), microcontrollers or microproces- . ^ ^ i- . t . i - i - 

/ • u „ by execution of an application based on said at least one 

sors (an X86 microprocessor, a Pentium microprocessor or ^ . 

an Advanced RISC Controller (ARM), as examples), as just characlenstic. 

^ , rr .1, 1 u „i 9. The method of claim 1, wherem the layer comprises a 

a few examples. Furthermore, the phrase Computer system 

mav refer to any tvpe of processor-based system that may ^^^^P^ V^ci- i u - <u , c 

.f, ^ i' , A , ^ 4„ o« ..««i:-.„™ 10. The methtxl of claim 1, wherein the act of receiving 

mcludeadesktopcomputer, a laptop computer, an appliance , 

or a set-top box, as just a few examples. Thus, the invention comprtses. 

is not intended lo be limited to the illuslraled computer the packet from a network. 

system 50 but rather, the computer system 50 is an example The method of claim 1, further comprismg: 

of one of many embodiments of the invention. determining whether a security key is available for the 

The host bus 58 may be coupled by a bridge, or memory " packet; and 

hub 60, to an Accelerated Graphics Port (AGP) bus 62. The prcKCssmg ot the packet based on the dclermmation. 

AGP is described in detail in the Accelerated Graphics Port 12. The method of claim 11, wherein the aclof proccssmg 

Interface Specification, Revision 1.0, published in Jul. 31, comprises: 

1996, by Intel Corporation of Santa Clara, Calif. The AGP decrypting data of the packet. 

bus 62 may be coupled to. for example, a video controUcr 64 13. The method of claim 11 , wherein the act of processing 

thai contK>Ls a display 65. 'ITic memory hub 60 may also comprises: 

couple the AGP bus 62 and the host bus SH to a memory bus encrypting data of the packet. 

61. The memory bus 61, in turn, may be coupled to a system 14. The method of claim 11, further comprising: 

memory 56 that may, its examples, store the buffers 304 and using said at least one characteristic to check an integrity 

a copy of the driver program 57. of the packet. 

The memory bub 60 may also be coupled (via a hub link 15. An apparatus for use with a computer system capable 

66) to another bridge, or input/output (1/0) hub 68, that is of executing software of a protocol stack to extract at least 

coupled to an I/O expansion bus 70 and the PCI bus 72. Ilie one characteristic of a packet, comprising: 
I/O hub 68 may also be coupled to, as examples, a CO-ROM 50 an interface adapted lo receive the packet, the packet 

drive 82 and a hard disk drive 84. The 1/0 expan.sion bus 70 including a header indicating said at least one charac- 

may be coupled to an I/O controller 74 that controls opera- lerislic; and 

tion of a floppy disk drive 76 and receives input data from a circuit adapted lo: 

a keyboard 78 and a mouse 80, as examples. parse the header to extract said at least one character- 
Other embodimenis are within the scope of the following 65 istic of the packet without causing the computer 
claims. For example, a peripheral device other than a .system to execute the software, and 
network controller may implement the above-described process the packet based on the extracted characteristic. 
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16. The apparatus of claim 15, wherein said at least one 
characteristic comprises: 

a port number being associated with an application pro- 
gram. 

17. The apparatus of claim 15, wherein said at least one 
characteristic comprises: 

a security attribute associated with the packet. 

18. The apparatus of claim 15, wherein said at least one 
characteristic comprises: 

a type of the packet. 

19. The apparatus of claim 15, wherein the circuit is 
further adapted to: 

use said at least one characteristic to associate the packet 
with a flow. 

20. The apparatus of claim 15, wherein the circuit is 
further adapted to: 

determine whether a security key is available for the 
packet; and 

further base the processing of the packet based on the 
determination. 

21. The apparatus of claim 15, wherein the apparatus 
comprises a network controller. 

22. A computer system comprising: 

a processor adapted to execute software of a network 
stack to extract at least one characteristic of a packet; 
and 

a peripheral device adapted to: 

receive the packet, the packet including a header indi- 
cating said at least one characteristic. 
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parse the header to extract said at least one 

characteristic, and 
at least partially process the packet based on the at least 
one extracted characteristic. 
5 23. The computer system of claim 22, wherein the soft- 
ware comprises a network layer. 

24. The computer system of claim 22, wherein said at 
least one characteristic comprises: 

a port number associated with an application program. 

25. The computer system of claim 22, wherein said at 
least one characteristic comprises: 

a security attribute being associated with the packet, 

26. The computer system of claim 22, wherein said at 
35 least one characteristic comprises: 

a type of the packet. 

27. The computer system of claim 22, wherein the periph- 
eral device is fiirther adapted to: 

2Q use said at least one characteristic to associate the packet 
with a flow. 

28. The computer system of claim 22, wherein the periph- 
eral device is fiirther adapted to: 

determine whether a security key is available for the 
25 packet; and 

further base the processing of the packet based on the 
determination. 

29. The computer system of claim 22, wherein the periph- 
eral device comprises a network controller. 

* « * « * 
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